Computer errors can be extremely frustrating to the computer user. Having a computer "crash" or "freeze" in the middle of a project can erase hours of hard work. Although a computer can typically be restarted after such a crash, some program errors are not so easily remedied. As an example, a fatal internal system error can render a computer program inoperative. That is, the program user may run into the same crash or error each time the program is used. Thus, the user is not able to merely reboot and start over again. Instead, the user must determine the cause of the error and attempt to solve the problem before using the program again.
In one attempt to alleviate difficulties associated with internal system errors, some systems provide stack traces upon the occurrence of a fatal internal system error. A stack trace provides a list of procedure calls used by the program until just prior to the internal system error. Thus, once the program crash occurs, the user is theoretically able to evaluate, in chronological order, the program routines performed prior to the internal system error. Although stack traces are intended to provide insight to the cause or causes of the internal system error, often program users have no idea what to do with the stack trace information. That is, the stack trace does not assist most users in determining the cause of the internal system error. Therefore, the user must seek assistance from a program expert such as, for example, a customer support technician in order to determine a solution to the internal system error. Such an approach requires the program user to seek out and contact the program expert, explain the internal system error, describe the stack trace contents, and then attempt to implement any suggested solutions. As a result, the program user is subjected to significant inconvenience and experiences substantial program downtime.
As yet another drawback, many prior art stack traces are presented in encoded form. That is, if the programmers of the crashed program do not want the specific procedural call names and orders to be publicly available, the stack trace will be in encoded form. Therefore, even if the user has the knowledge and ability to interpret a stack trace, the program user is restricted from knowing the content of the stack trace. As in the above example, the user must seek assistance from a program expert such as, for example, a customer support technician. More specifically, the user must seek assistance from a program expert having the authority and ability to decode the stack trace. Such an approach requires the program user to seek out and contact the program expert, explain the internal system error, describe the encoded stack trace contents, and then attempt to implement any suggested solutions. Again, the program user is subjected to significant inconvenience and experiences substantial program downtime.
Thus, a need exists for a method and system which automatically determines the nature of a program system error. A further need exists for a method and system which quickly reports the source of the system error to the user of the program which has suffered the system error. Yet another need exists for a method and system which meets the above needs without requiring extensive customer support intervention.